Automated Debugging: Are We Close

2 Computer Automated Debugging: Are We Close? F or the past 50 years, software engineers have enjoyed tremendous productivity increases as more and more tasks have become automated. Unfortunately, debugging—the process of identifying and correcting a fail-ure's root cause—seems to be the exception, remaining as labor-intensive and painful as it was five decades ago. An engineer or programmer still has to notice something, wonder why it happens, set up hypotheses , and then attempt to confirm or refute them. In theory, there is no reason to continue this legacy. Debugging can be just as disciplined, systematic, and quantifiable as any other area of software engineer-ing—which means that we should eventually be able to automate at least part of it. So far, research has concentrated on program analysis because of its roots in compiler construction. But analysis requires complete knowledge about the program being examined and does not scale well to large programs. Testing is another way to gather knowledge about a program because it helps weed out the circumstances that aren't relevant to a particular failure. If testing reveals that only three of 25 user actions are relevant, for example, you can focus your search for the fail-ure's root cause on the program parts associated with these three actions. If you can automate the search process, so much the better. This is the premise of Delta Debugging, an algorithm that uses the results of automated testing to systematically narrow the set of failure-inducing circumstances. 1 Programmers supply a test function for each bug and hardcode it into any imperative language. The test function checks a set of changes to determine if the failure is present or if the outcome is unresolved and feeds that information to the Delta Debugging code. Programmers can either hardcode the algorithm, available from the Delta Debugging Web site adapt the core of Wynot, a prototype debugger written in Python that runs on a Unix or Linux system. Both the algorithm and Wynot (short for " worked yesterday , not today ") fit with any imperative language, and Wynot is platform independent. Work on a " debugging server " is in progress. The idea is to have a programmer submit the program to be examined along with invocation details to a Web site, choose from a menu how to identify a failure, and click on " Submit. " Wynot will then automatically isolate the failure-inducing circumstances …